The invention field relates to methods and apparatus for communicating, registering and processing a trap/event information signal in a network for the events that occur in agent devices in the network. More particularly, the subject embodiments relate to a trap/event registration mechanism wherein a management system registers distinct trap/event types on separate management system input ports, wherein an event signal at a port corresponds to a unique trap/event type.
Network devices and systems typically have management protocols like SNMP (Simple Network Management Protocol) which allows a management system to register for events that occur in the device. There can be multiple events occurring inside the device in which the management system might be interested. SNMP trap/event registration and processing essentially involves two network systems. A trap/event generator system typically relates to any embedded device agent/computing system agent which sends a message when some state change happens inside the device and has to be acted upon for the device's optimum functionality. A trap listener system relates to any management system which is interested in receiving the messages from a trap/event generator and wants to act on the message. The device management system is responsible for managing the device/agent (e.g. printers) by interrogating the device's state and status using well known protocols such as SNMP and/or SOAP (an XML protocol) based web devices. Usually a management system uses one of two methods to talk to a device/agent. An active device polling method involves polling the device periodically by the device management system to gather/interrogate the device about its state and status or events happening inside the device. A passive event/trap listening method is used by a device management system to listen on management system ports for the traps/events happening inside the device. Whenever a trap/event occurs inside the device/agent/printer, the device sends the event to the interested device management system at a specific port for an application to act upon those events. A device management system shows interest in receiving a trap/event by registering itself as an intended trap/event recipient party by calling the device's trap/event registration method. The device management system provides specifics (such as address, port and type of trap/event), as parameters to the registration request.
The current protocol mechanism for the trap registration process is to register all the interested traps/events and have a device report all these events at the standard trap port (e.g. 162 of a management system. So whenever any trap/event occurs inside the device, they are all received on the same standard port number. Some systems involve decoding the signal to identify the trap/event (see U.S. Pat. No. 6,336,184). The systems which do not involve decoding have no indication of what kind of trap/event has occurred inside the device and thus must determine the type of event that has happened into the device by polling the device to get more information to determine what trap/event occurred.
FIG. 1 shows a typical current management system user interface for a trap/event registration. The management system always uses the well-known port 162. For example, if the device management system is interested in receiving traps/events for virus intrusion, printer faults, low supplies, authentication failure and printer/device warm, it will register itself with the device as an intended recipient. So whenever any of the above-mentioned traps/events occurs inside the device, the device agent will send the alert to port 162. A management system has no indication of what kind of trap/event has occurred inside the device agent if it cannot decode the received trap/event signal packet. The management system only knows that some event has happened inside the device upon which it must act. It will have to poll and probe the device again to find out what event exactly occurred in the device and get the associated event data from the device. Such polling will have to be done for each and every trap/event received by the management system, causing scalability, and performance issues. It will also cause unnecessary network traffic.
FIG. 2 depicts such a use case scenario. The network system includes a management system 10 with embedded a printers/device/agent 12 and communication is effected between these devices via processes for trap registration 14, trap processing 16 and trap listening 18. The first step in the process involves registering for virus intrusion, printer fault, low supplies, authentication failure and cold start traps. The second step is to start a trap listener process to listen for incoming traps. The registration process is illustrated in steps 20 and 24, at which point a device/agent becomes registered for sending trap/event notification signals to the management system port P1. The step 22 illustrates the trap listener process which must be started by management system to receive the trap(s). When a trap/event occurs at the device/agent/printer, the trap/event signal is received 26 at the trap listener port and the management system then receives the trap information, but if no decoding is involved, there is no indication of what type of the trap/event has actually occurred at the device/agent. In order to obtain such information, the management system trap processor queries the device/agent 30 whereupon the type of trap related information is communicated by a device/agent to the management system processor and thereafter the management system is notified 32 about trap details and device status.
Thus, there is a need for SNMP communication signal management system which does not have to decode device/agent trap/event signals, or which involves subsequent polling to a trap/event signal received at a single management port.